Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.162 < prev next >

Wrap

Text File | 1996-02-12 | 27.8 KB | 710 lines

Frequently Asked Questions (FAQS);faqs.162 The Apple IIgs records raw data in the same format as the Mac, but uses a 0 byte as a terminator; samples with value 0 are replaced by 1. File conversions ---------------- SOX --- The most versatile tool for converting between various audio formats is SOX ("Sound Exchange"). It can read and write various types of audio files, and optionally applies some special effects (e.g. echo, channel averaging, or rate conversion). SOX recognizes all filename extensions listed above except ".snd", which would be ambiguous anyway, and ".wav" (but there's a patch, see below). Use type ".au" for NeXT ".snd" files. Mac and PC ".snd" files are completely described by these parameters: -t raw -b -u -r 11000 (or -r 22000 or -r 7333 or -r 5500; 11000 seems to be the most common rate). The source for SOX, version 5, was posted to alt.sources, and should be widely archived. To save you the trouble of hunting it down, it can be gotten by anonymous ftp from wuarchive.wustl.edu, in the directory usenet/alt.sources/articles, files 5581.Z through 5585.Z. (These files are compressed news articles containing shar files, if you hadn't guessed.) I am sure many sites have similar archives, I'm just listing one that I know of and which carries a lot of this kind of stuff. (Also see the appendix if you don't have Internet access.) A compressed tar file containing the same version of SOX is available by anonymous ftp from ftp.cwi.nl [192.16.184.180], in /pub/sox*.tar.Z. You may be able to locate a nearer version using archie! Ports of SOX: - The source as posted should compile on any UNIX system with 4-byte integers. - A PC version is available by ftp from ftp.cwi.nl (see above) as pub/sox4*.zip; also available from the garbo mail server. - The latest Amiga SOX (corresponding to version 5) is available via anonymous ftp to wuarchive.wustl.edu, files systems/amiga/audio/utils/amisox*. (See below for a non-SOX solution.) - Work is currently in progress to get SOX ported to VMS (watch comp.os.vms for announcements). SOX usage hints: - Often, the filename extension of sound files posted on the net is wrong. Don't give up, try a few other possibilities using the "-t <type>" option. Remember that the most common file type is unsigned bytes, which can be indicated with "-t ub". You'll have to guess the proper sampling rate, but often it's 11k or 22k. - In particular, with SOX version 4 (or earlier), you have to specify "-t 8svx" for files with an .iff extension. - When converting linear samples to U-LAW using the .au type for the output file, you must specify "-U" for the output file, otherwise you will end up with a file containing a NeXT/Sun header but linear samples -- only the NeXT will play such files correctly. Also, you must explicitly specify an output sampling rate with "-r 8000". (This may seem fixed for most cases in version 5, but it is still occasionally necessary, so I'm keeping this warning in.) Sun Sparc --------- On Sun Sparcs, starting at SunOS 4.1, a program "raw2audio" is provided by Sun (in /usr/demo/SOUND -- see below) which takes a raw U-LAW file and turns it into a ".au" file by prefixing it with an appropriate header. NeXT ---- On NeXTs, you can usually rename .au files to .snd and it'll work like a charm, but some .au files lack header info that the NeXT needs. This can be fixed by using sndconvert: sndconvert -c 1 -f 1 -s 8012.8210513 -o nextfile.snd sunfile.au SGI Indigo and Personal IRIS ---------------------------- SGI supports a program sfconvert, similar in spirit to SOX (in /usr/sbin in IRIX version 4.0). Also note that the sfplay program (see the next section) can do on-the-fly conversion for several popular formats. Amiga ----- Mike Cramer's SoundZAP can do no effects except rate change and it only does conversions to IFF, but it is generally much faster than SOX. (Ftp'able from the same directory as amisox above.) Tandy ----- The Tandy 1000 uses a (proprietary?) compressed format. There is a PD Mac to Tandy conversion program called CONVERT. Playing audio files on UNIX --------------------------- The commands needed to play an audio file depend on the file format and the available hardware and software. Most systems can only directly play sound in their native format; use a conversion program (see above) to play other formats. Sun Sparcstation running SunOS 4.x ---------------------------------- Raw U-LAW files can be played using "cat file >/dev/audio". A whole package for dealing with ".au" files is provided by Sun on an experimental basis, in /usr/demo/SOUND. You may have to compile the programs first. (If you can't find this directory, either you are not running SunOS 4.1 yet, or your system administrator hasn't installed it -- go ask him for it, not me!) The program "play" in this directory recognizes all files in Sun/NeXT format, but a SS 1 or 2 can play only those using U-LAW encoding at 8 k -- the SS 10 hardware plays other encodings, too. If you ca't find "play", you can also cat a ".au" file to /dev/audio, if it uses U-LAW; the header will sound like a short burst of noise but the rest of the data will sound OK (really, the only difference in this case between raw U-LAW and ".au" files is the header; the U-LAW data is exactly the same). Finally, OpenWindows 3.0 has a full-fledged audio tool. You can drop audio file icons into it, edit them, etc. Sun Sparcstation running Solaris 2.0 ------------------------------------ Under SVR4 (and hence Solaris 2.0), writing to /dev/audio from the shell is a bad idea, because the device driver will flush its queue as soon as the file is closed. Use "audioplay" instead. The supported formats and sampling rates are the same as above. NeXT ---- On NeXT machines, the standard "sndplay" program can play all NeXT format files (this include Sun ".au" files). It supports at least U-LAW at 8 k and 16 bits samples at 22 or 44.1 k. It attempts on-the-fly conversions for other formats. Sound files are also played if you double-click on them in the file browser. SGI Indigo and Personal IRIS ---------------------------- On SGI Indigo and the 4D/30 and /35 Personal IRIS workstations, the program "sfplay" (in /usr/sbin) plays AIFF files, if the sampling rate is one of 8000, 11025, 16000, 22050, 32000, 44100, or 48000. On the Personal IRIS, you need to have the audio board installed (check the output from hinv) and you must run IRIX 3.3.2 or 4.0 or higher. "Workspace" plays audio files if you double click on them. There is no simple /dev/audio interface on these SGI machines. (There was one on 4D/25 machines, reading and writing signed linear 8-bit samples at rates of 8, 16 and 32 k.) A program "playulaw" was posted as part of the "radio 2.0" release that I posted to several source groups recently; it plays raw U-LAW files on the Indigo or Personal IRIS audio hardware. Sony NEWS --------- The Sony RISC-NEWS line (NWS-3250 laptop, NWS-37xx desktop, NWS-38xx desktop w/ IOP) also has builtin sound capabilities. You can also buy external boards for the older NEWS machines or to add extra channels to the new machines. In the default mode (8k/8-bit), Sun .au files are directly supported (you can 'cat' .au files to /dev/sb and have them play). Vaxstation 4000 --------------- ".au" files can be played by COPYING them to device "SOA0:". This device is set up by enabling the driver SODRIVER, as described below: DEC's sound stuff is like most other new toy. Hardware first, THEN the software. DEC will soon be releasing a layered product called DECsound, which will let you record, play, and (possibly) manipulate sound files. Third party product(s) have ALREADY hit the market. Enabling SODRIVER: (you can use the following command file) $!---------------- cut here ------------------------------- $! sound_setup.com enable SOUND driver $ run sys$system:sysgen connect soa0 /adapter=0 /csr=%x0e00 /vector=%o304 /driver=sodriver exit $ exit $!----------------- cut here ------------------------------------ The external audio port comes with a telephone-jack-like port. For starters, you can plug a telephone RECEIVER right into this port to hear your first sound files. After that, you can use the adapter (that came with the VaxStation), and plug in a small set of stereo speakers (the kind you'd plug into a WALKMAN, for example), for more volume. Others ------ Most other UNIX boxes don't have audio hardware and thus can't play audio data. Playing audio files on micros ----------------------------- Most micros have at least a speaker built in, so theoretically all you need is the right software. Unfortunately most systems don't come bundled with sound-playing software, so there are many public domain or shareware software packages, each with their own bugs and features. Most separate sound recording hardware also comes with playing software, most of which can play sound (in the file format used by that hardware) even on machines that don't have that hardware installed. Chris S. Craig announces the following software for PCs: ScopeTrax This is a complete PC sound player/editor package. Sounds can be played back at ANY rate between 1kHz to 65kHz through the PC speaker or the Sound Blaster. It supports several file formats including VOC, IFF/8SVX, raw signed and raw unsigned. A separate executable is provided to convert .au and mu-law to raw format. ScopeTrax requires EGA/VGA graphics for editing and displaying sounds on a REALTIME oscilloscope. The package also includes: * An expanded memory player which can play sounds larger than 640K in size. * Basic (rough) sound compression/uncompression utilities. * Complete documentation. The package is FREEWARE! It is available on SIMTEL in the PD1:[MSDOS.SOUND] directory. One of the appendices below contains a list of more programs to play sound on the PC. For sounds on Atari STs - programs are in the atari/sound/players directory on atari.archive.umich.edu (141.211.164.8). Malcolm Slaney from Apple writes: "We do have tools to play sound back on most of our Unix hosts. We wrote a program called TcpPlay that lets us read a sound file on a Unix host, open a TCP/IP connection to the Mac on my desk, and plays the file. We think of it as X windows for sound (at least a step in that direction.) This software is available for anonymous FTP from ftp.apple.com. Look for ~ftp/pub/TcpPlay/TcpPlay.sit.hqx. Finally, there are MANY tools for working with sound on the Macintosh. Three applications that come to mind immediately are SoundEdit (formerly by Farralon and now by MacroMind/Paracomp), Alchemy and Eric Keller's Signalyze. There are lots of other tools available for sound editing (including some of the QuickTime Movie tools.)" On a Tandy 1000, sounds can be played and recorded with DeskMate Sound (SOUND.PDM), or if they not stored in compressed format, they can also be played be a program called PLAYSND. No indication of whether PLAYSND is PD or not. It hasn't been updated since March of 89. The Sound Site Newsletter ------------------------- An electronic publication with lots of info about digitised sound and sound formats, albeit mostly on micros, is "The Sound Site Newsletter". So far, 8 issues have appeared, the last in January 1992. Issues can be ftp'ed from saffron.inset.com, directory directory pub/rogue/newsletters, or from ccb.ucsf.edu, Pub/Sound_list/Sound.Newsletters. Posting sounds -------------- The newsgroup alt.binaries.sounds.misc is dedicated to postings containing sound. (Discussions related to such postings belong in alt.binaries.sounds.d.) There is no set standard for posting sounds; uuencoded files in most popular formats are welcome, if split in parts under 50 kBytes. To accomodate automatic decoding software (such as the ":decode" command of the nn newsreader), please place a part indicator of the form (mm/nn) at the end of your subject meaning this is number mm of a total of nn part. It is recommended to post sounds in the format that was used for the original recording; conversions to other formats often lose information and would do people with identical hardware as the poster no favor. For instance, convering 8-bit linear sound to U-LAW loses the lower few bits of the data, and rate changing conversions almost always add noise. Converting from U-LAW to linear requires expansion to 16 bit samples if no information loss is allowed! U-LAW data is best posted with a NeXT/Sun header. If you have to post a file in a headerless format (usually 8-bit linear, like ".snd"), please add a description giving at least the sampling rate and whether the bytes are signed (zero at 0) or unsigned (zero at 0200). However, it is highly recommended to add a header that indicates the sampling rate and encoding scheme; if necessary you can use SOX to add a header of your choice to raw data. Compression of sound files usually isn't worth it; the standard "compress" algorithm doesn't save much when applied to sound data (typically at most 10-20 percent), and compression algorithms specifically designed for sound (e.g. NeXT's) are usually proprietary. (See also the section "Compression schemes" earlier.) Appendices ========== Here are some more detailed pieces of info that I received by e-mail. They are reproduced here virtually without much editing. ------------------------------------------------------------------------ FTP access for non-internet sites --------------------------------- From the sci.space FAQ: Sites not connected to the Internet cannot use FTP directly, but there are a few automated FTP servers which operate via email. Send mail containing only the word HELP to ftpmail@decwrl.dec.com or bitftp@pucc.princeton.edu, and the servers will send you instructions on how to make requests Also: FAQ lists are available by anonymous FTP from pit-manager.mit.edu (18.72.1.58) and by email from mail-server@pit-manager.mit.edu (send a message containing "help" for instructions about the mail server). ------------------------------------------------------------------------ AIFF Format (Audio IFF) and AIFC -------------------------------- This format was developed by Apple for storing high-quality sampled sound and musical instrument info; it is also used by SGI and several professional audio packages (sorry, I know no names). An extension, called AIFC or AIFF-C, supports compression (see the last item below). I've made a BinHex'ed MacWrite version of the AIFF spec (no idea if it's the same text as mentioned below) available by anonymous ftp from ftp.cwi.nl [192.16.184.180]; the file is /pub/AudioIFF1.2.hqx. But you may be better off with the AIFF-C specs, see below. Mike Brindley (brindley@ece.orst.edu) writes: "The complete AIFF spec by Steve Milne, Matt Deatherage (Apple) is available in 'AMIGA ROM Kernal Reference Manual: Devices (3rd Edition)' 1991 by Commodore-Amiga, Inc.; Addison-Wesley Publishing Co.; ISBN 0-201-56775-X, starting on page 435 (this edition has a charcoal grey cover). It is available in most bookstores, and soon in many good librairies." Finally, Mark Callow writes (in comp.sys.sgi): "I have placed a PostScript version of the AIFF-C specification on sgi.sgi.com for public ftp. It is in the file sgi/aiff-c.9.26.91.ps. sgi.sgi.com's internet host number is (I think) 192.48.153.1." ------------------------------------------------------------------------ The NeXT/Sun audio file format ------------------------------ Here's the complete story on the file format, from the NeXT documentation. (Note that the "magic" number is ((int)0x2e736e64), which equals ".snd".) Also, at the end, I've added a litte document that someone posted to the net a couple of years ago, that describes the format in a bit-by-bit fashion rather than from C. I received this from Doug Keislar, NeXT Computer. This is also the Sun format, except that Sun doesn't recognize as many format codes. I added the numeric codes to the table of formats and sorted it. SNDSoundStruct: How a NeXT Computer Represents Sound The NeXT sound software defines the SNDSoundStruct structure to represent sound. This structure defines the soundfile and Mach-O sound segment formats and the sound pasteboard type. It's also used to describe sounds in Interface Builder. In addition, each instance of the Sound Kit's Sound class encapsulates a SNDSoundStruct and provides methods to access and modify its attributes. Basic sound operations, such as playing, recording, and cut-and-paste editing, are most easily performed by a Sound object. In many cases, the Sound Kit obviates the need for in-depth understanding of the SNDSoundStruct architecture. For example, if you simply want to incorporate sound effects into an application, or to provide a simple graphic sound editor (such as the one in the Mail application), you needn't be aware of the details of the SNDSoundStruct. However, if you want to closely examine or manipulate sound data you should be familiar with this structure. The SNDSoundStruct contains a header, information that describes the attributes of a sound, followed by the data (usually samples) that represents the sound. The structure is defined (in sound/soundstruct.h) as: typedef struct { int magic; /* magic number SND_MAGIC */ int dataLocation; /* offset or pointer to the data */ int dataSize; /* number of bytes of data */ int dataFormat; /* the data format code */ int samplingRate; /* the sampling rate */ int channelCount; /* the number of channels */ char info[4]; /* optional text information */ } SNDSoundStruct; SNDSoundStruct Fields magic magic is a magic number that's used to identify the structure as a SNDSoundStruct. Keep in mind that the structure also defines the soundfile and Mach-O sound segment formats, so the magic number is also used to identify these entities as containing a sound. dataLocation It was mentioned above that the SNDSoundStruct contains a header followed by sound data. In reality, the structure only contains the header; the data itself is external to, although usually contiguous with, the structure. (Nonetheless, it's often useful to speak of the SNDSoundStruct as the header and the data.) dataLocation is used to point to the data. Usually, this value is an offset (in bytes) from the beginning of the SNDSoundStruct to the first byte of sound data. The data, in this case, immediately follows the structure, so dataLocation can also be thought of as the size of the structure's header. The other use of dataLocation, as an address that locates data that isn't contiguous with the structure, is described in "Format Codes," below. dataSize, dataFormat, samplingRate, and channelCount These fields describe the sound data. dataSize is its size in bytes (not including the size of the SNDSoundStruct). dataFormat is a code that identifies the type of sound. For sampled sounds, this is the quantization format. However, the data can also be instructions for synthesizing a sound on the DSP. The codes are listed and explained in "Format Codes," below. samplingRate is the sampling rate (if the data is samples). Three sampling rates, represented as integer constants, are supported by the hardware: Constant Sampling Rate (samples/sec) SND_RATE_CODEC 8012.821 (CODEC input) SND_RATE_LOW 22050.0 (low sampling rate output) SND_RATE_HIGH 44100.0 (high sampling rate output) channelCount is the number of channels of sampled sound. info info is a NULL-terminated string that you can supply to provide a textual description of the sound. The size of the info field is set when the structure is created and thereafter can't be enlarged. It's at least four bytes long (even if it's unused). Format Codes A sound's format is represented as a positive 32-bit integer. NeXT reserves the integers 0 through 255; you can define your own format and represent it with an integer greater than 255. Most of the formats defined by NeXT describe the amplitude quantization of sampled sound data: Value Code Format 0 SND_FORMAT_UNSPECIFIED unspecified format 1 SND_FORMAT_MULAW_8 8-bit mu-law samples 2 SND_FORMAT_LINEAR_8 8-bit linear samples 3 SND_FORMAT_LINEAR_16 16-bit linear samples 4 SND_FORMAT_LINEAR_24 24-bit linear samples 5 SND_FORMAT_LINEAR_32 32-bit linear samples 6 SND_FORMAT_FLOAT floating-point samples 7 SND_FORMAT_DOUBLE double-precision float samples 8 SND_FORMAT_INDIRECT fragmented sampled data 9 SND_FORMAT_NESTED ? 10 SND_FORMAT_DSP_CORE DSP program 11 SND_FORMAT_DSP_DATA_8 8-bit fixed-point samples 12 SND_FORMAT_DSP_DATA_16 16-bit fixed-point samples 13 SND_FORMAT_DSP_DATA_24 24-bit fixed-point samples 14 SND_FORMAT_DSP_DATA_32 32-bit fixed-point samples 15 ? 16 SND_FORMAT_DISPLAY non-audio display data 17 SND_FORMAT_MULAW_SQUELCH ? 18 SND_FORMAT_EMPHASIZED 16-bit linear with emphasis 19 SND_FORMAT_COMPRESSED 16-bit linear with compression 20 SND_FORMAT_COMPRESSED_EMPHASIZED A combination of the two above 21 SND_FORMAT_DSP_COMMANDS Music Kit DSP commands 22 SND_FORMAT_DSP_COMMANDS_SAMPLES ? Most formats identify different sizes and types of sampled data. Some deserve special note: -- SND_FORMAT_DSP_CORE format contains data that represents a loadable DSP core program. Sounds in this format are required by the SNDBootDSP() and SNDRunDSP() functions. You create a SND_FORMAT_DSP_CORE sound by reading a DSP load file (extension ".lod") with the SNDReadDSPfile() function. -- SND_FORMAT_DSP_COMMANDS is used to distinguish sounds that contain DSP commands created by the Music Kit. Sounds in this format can only be created through the Music Kit's Orchestra class, but can be played back through the SNDStartPlaying() function. -- SND_FORMAT_DISPLAY format is used by the Sound Kit's SoundView class. Such sounds can't be played. -- SND_FORMAT_INDIRECT indicates data that has become fragmented, as described in a separate section, below. -- SND_FORMAT_UNSPECIFIED is used for unrecognized formats. Fragmented Sound Data Sound data is usually stored in a contiguous block of memory. However, when sampled sound data is edited (such that a portion of the sound is deleted or a portion inserted), the data may become discontiguous, or fragmented. Each fragment of data is given its own SNDSoundStruct header; thus, each fragment becomes a separate SNDSoundStruct structure. The addresses of these new structures are collected into a contiguous, NULL-terminated block; the dataLocation field of the original SNDSoundStruct is set to the address of this block, while the original format, sampling rate, and channel count are copied into the new SNDSoundStructs. Fragmentation serves one purpose: It avoids the high cost of moving data when the sound is edited. Playback of a fragmented sound is transparent-you never need to know whether the sound is fragmented before playing it. However, playback of a heavily fragmented sound is less efficient than that of a contiguous sound. The SNDCompactSamples() C function can be used to compact fragmented sound data. Sampled sound data is naturally unfragmented. A sound that's freshly recorded or retrieved from a soundfile, the Mach-O segment, or the pasteboard won't be fragmented. Keep in mind that only sampled data can become fragmented. _________________________ >From mentor.cc.purdue.edu!purdue!decwrl!ucbvax!ziploc!eps Wed Apr 4 23:56:23 EST 1990 Article 5779 of comp.sys.next: Path: mentor.cc.purdue.edu!purdue!decwrl!ucbvax!ziploc!eps >From: eps@toaster.SFSU.EDU (Eric P. Scott) Newsgroups: comp.sys.next Subject: Re: Format of NeXT sndfile headers? Message-ID: <445@toaster.SFSU.EDU> Date: 31 Mar 90 21:36:17 GMT References: <14978@phoenix.Princeton.EDU> Reply-To: eps@cs.SFSU.EDU (Eric P. Scott) Organization: San Francisco State University Lines: 42 In article <14978@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >I'd like to take a program I have that converts Macintosh sound files >to NeXT sndfiles and polish it up a bit to go the other direction as >well. Two people have already submitted programs that do this (Christopher Lane and Robert Hood); check the various NeXT archive sites. > Could someone please give me the format of a NeXT sndfile >header? "big-endian" 0 1 2 3 +-------+-------+-------+-------+ 0 | 0x2e | 0x73 | 0x6e | 0x64 | "magic" number +-------+-------+-------+-------+ 4 | | data location +-------+-------+-------+-------+ 8 | | data size +-------+-------+-------+-------+ 12 | | data format (enum) +-------+-------+-------+-------+ 16 | | sampling rate (int) +-------+-------+-------+-------+ 20 | | channel count +-------+-------+-------+-------+ 24 | | | | | (optional) info string 28 = minimum value for data location data format values can be found in /usr/include/sound/soundstruct.h Most common combinations: sampling channel data rate count format voice file 8012 1 1 = 8-bit mu-law system beep 22050 2 3 = 16-bit linear CD-quality 44100 2 3 = 16-bit linear ------------------------------------------------------------------------ IFF/8SVX Format --------------- Newsgroups: alt.binaries.sounds.d,alt.sex.sounds Subject: Format of the IFF header (Amiga sounds) Message-ID: <2509@tardis.Tymnet.COM> From: jms@tardis.Tymnet.COM (Joe Smith) Date: 23 Oct 91 23:54:38 GMT Followup-To: alt.binaries.sounds.d Organization: BT North America (Tymnet) The first 12 bytes of an IFF file are used to distinguish between an Amiga picture (FORM-ILBM), an Amiga sound sample (FORM-8SVX), or other file conforming to the IFF specification. The middle 4 bytes is the count of bytes that follow the "FORM" and byte count longwords. (Numbers are stored in M68000 form, high order byte first.) ------------------------------------------ FutureSound audio file, 15000 samples at 10.000KHz, file is 15048 bytes long. 0000: 464F524D 00003AC0 38535658 56484452 FORM..:.8SVXVHDR F O R M 15040 8 S V X V H D R 0010: 00000014 00003A98 00000000 00000000 ......:......... 20 15000 0 0 0020: 27100100 00010000 424F4459 00003A98 '.......BODY..:. 10000 1 0 1.0 B O D Y 15000 0000000..03 = "FORM", identifies this as an IFF format file. FORM+00..03 (ULONG) = number of bytes that follow. (Unsigned long int.) FORM+03..07 = "8SVX", identifies this as an 8-bit sampled voice. ????+00..03 = "VHDR", Voice8Header, describes the parameters for the BODY. VHDR+00..03 (ULONG) = number of bytes to follow. VHDR+04..07 (ULONG) = samples in the high octave 1-shot part. VHDR+08..0B (ULONG) = samples in the high octave repeat part. VHDR+0C..0F (ULONG) = samples per cycle in high octave (if repeating), else 0. VHDR+10..11 (UWORD) = samples per second. (Unsigned 16-bit quantity.) VHDR+12 (UBYTE) = number of octaves of waveforms in sample. VHDR+13 (UBYTE) = data compression (0=none, 1=Fibonacci-delta encoding). VHDR+14..17 (FIXED) = volume. (The number 65536 means 1.0 or full volume.)